Prerequisites for the Nodinite Windows Server Monitoring Agent

Nodinite Windows Server Monitoring Agent delivers robust, secure, and scalable monitoring for your entire Windows Server landscape. This page details all prerequisites to ensure a seamless installation, optimal connectivity, and compliance with best practices.

• ✅ Secure and scalable monitoring for on-premises and cloud environments
• ✅ All software, user rights, and firewall requirements in one place
• ✅ Expert guidance for PowerShell, WinRM, and Service Bus setup
• ✅ Avoid common pitfalls with clear troubleshooting and FAQ links

This page outlines the prerequisites for installing and running the Nodinite Windows Server Monitoring Agent. In Nodinite v7, the agent is hosted as an IIS web site, which is the recommended model for enabling HTTPS/TLS transport.

Note

For secure production deployments, prefer TLS-protected communication wherever possible: host the agent over HTTPS when it runs remotely in IIS, and use PowerShell Remoting over HTTPS (WinRM on port 5986) instead of plain HTTP. This reduces exposure when PowerShell monitoring or remote actions are used.

• Hardening your Nodinite installation - Best practices for securing your environment, including the Windows Server Monitoring Agent.

This diagram shows how the agent connects to Windows Servers and pingable devices, supporting both local and remote PowerShell scripts.

You can install this agent on-premises using TCP/IP for local network access, or in the cloud/off-site using Service Bus Relaying. For more details, see the external link 'Azure Relay FAQs'.

We recommend keeping this agent close to Nodinite Core Services. This documentation covers local network setup (usually on the Nodinite application server)

Software Requirements

The Windows Server Monitoring Agent is a Windows Service and is usually installed on the Nodinite application server.

Tip

If you are exposing the agent as an IIS web site in Nodinite v7, configure HTTPS/TLS for the site and avoid plain HTTP. Treat PowerShell remoting the same way: use HTTPS (5986) when you can, and restrict firewall rules to the servers that truly need access.

Versions 6.2 and later do no longer require the Microsoft.Web.Administration assembly on Agent Host.
Versions 6.0 and later make use of the .NET Framework 4.8 or later.
Versions 5.4 and later make use of the .NET Framework 4.6.2 or later.
Versions prior to 5.4 make use of the .NET Framework 4.5.2 or later.

Remote Windows Servers with IIS to monitor must have these Windows features installed.

IIS 6 roles and features required for remote monitoring.

If you have three servers with IIS to monitor, you must install this feature on three servers
If you see entries in the Event Log like while activating CLSID {2B72133B-3F5B-4602-8952-803546CE3344}, please review the prereqs, restart, and make sure the following settings have been applied: Setting DCOM Security to Allow a User to Access a Computer Remotely

Management Service

If the IIS is a remote server to the Monitoring Agent; You must also enable remote connections and make sure the WMSVC service is operational. Please review the Remote Administration for IIS Manager for additional details.

1. Enable remote connections
2. Make sure to auto-start the VMSVC service
   
   Ensure to allow remote connections and set the 'WMSVC' service to start automatically.

Enable remote connections

1. In the IIS MMC, click on the node, then, on Management Service.
2. Check the Enable remote connections checkbox.

Click the Apply to persist the changes.

Click Apply to persist the changes.

Set WMSVC to start automatically

The WMSVC service installs with Startup Type set to Manual, which means that the service has to be manually restarted each time the server reboots or if HTTP.sys is stopped (WMSVC depends on HTTP.sys). Set the Startup Type to Automatic if you want WMSVC to start on system boot. Do this in the Services MMC console, or using this command line in an administrative command prompt:

sc.exe config WMSVC start= auto  

Note

The secure deployment model for PowerShell monitoring is to pair least-privilege accounts with TLS-protected transport. That means HTTPS for remote IIS hosting and WinRM over HTTPS for remote PowerShell whenever your environment allows it.

Supported Versions

Windows Server is ever-evolving, and Microsoft sometimes adds new functionality and/or deprecates older SDKs, methods and adjust policies. For Nodinite, this means you need to update Nodinite and our Windows Server Monitoring Agent from time to time.

Make sure to subscribe to our Release Notes.

What Windows User Rights does the Windows Server Monitoring agent require?

In Nodinite v7, the Windows Server Monitoring Agent is hosted as an IIS web site on a Windows Server (physical or virtual machine), typically on the same server as the Nodinite application. That hosting model allows you to use TLS for the agent endpoint.

Service Account Requirements

You must configure the IIS application pool identity used by the monitoring agent web site. That identity needs specific permissions:

1. Account Type

Choose one of the following account types:

• Domain account (recommended) - A user account from your Active Directory domain (e.g., DOMAIN\NodiniteAgent)
• Local named account - A local user account on the server where the agent is installed (e.g., .\NodiniteAgent)

Tip

Use a domain account if you plan to monitor multiple servers across your network. This simplifies permission management.

2. Required Permissions

The IIS identity needs two sets of permissions:

a) On the Agent Server (where the IIS web site is hosted):

• Log on as a service right - Only relevant to older service-hosted deployments, not the recommended v7 IIS-hosted model. Follow the 'How to set logon as a Windows service right' guide only if you are maintaining a legacy deployment.

b) On all Servers to monitor (Agent host and remote targets):

• Local Administrator membership - The IIS identity must be a member of the local Administrators group on every Windows Server the agent will monitor. This includes the Agent Server when the agent also monitors its host.

Important

Critical requirement: To monitor Windows Servers (local or remote), the IIS identity must have local administrator rights on each server being monitored. Without this, the agent cannot access WMI, performance counters, remote PowerShell, IIS management or other management operations required for full monitoring.

3. UAC Remote Token Filtering (Remote Servers Only)

When monitoring remote Windows Servers, User Access Control (UAC) may filter administrative tokens, causing "Access Denied" errors even when the service account is in the local Administrators group.

Symptoms:

• Error: Access is denied. (HRESULT: 0x80070005 E_ACCESSDENIED)
• Error: System.UnauthorizedAccessException: Access is denied
• Service account is in Administrators group but monitoring fails

Solution - Use Domain Administrator Account (Recommended):

Use an IIS identity that is a member of Domain Admins or Enterprise Admins if your security model allows it. Domain admin accounts bypass UAC token filtering on domain-joined servers.

Alternative Solution - Disable UAC Token Filtering:

If you cannot use a domain admin account, disable UAC token filtering on each remote server being monitored:

# Run on the remote server being monitored
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" `
    -Name "LocalAccountTokenFilterPolicy" -Value 1 -PropertyType DWord -Force

Warning

Disabling UAC filtering reduces security. Only use in controlled environments when domain admin accounts are not feasible. See How to Monitor Remote Scheduled Tasks for detailed troubleshooting.

Example Configuration

If you're using domain account DOMAIN\NodiniteAgent to monitor 5 Windows Servers:

1. ✅ Grant "Log on as a service" right on the Agent Server
2. ✅ Add DOMAIN\NodiniteAgent to the local Administrators group on all 5 remote servers
3. ✅ Configure the Windows Server Monitoring Agent service to run as DOMAIN\NodiniteAgent

Note

Security consideration: While local administrator rights are required for full monitoring capabilities (WMI, performance counters, IIS management), consider your organization's security policies. Some enterprises use dedicated monitoring accounts with restricted permissions or implement least-privilege access patterns. Consult your security team if standard administrator rights are not permitted.

What Firewall settings do the Nodinite Windows Server Monitoring agent require?

Where you install the Nodinite Windows Server Monitoring Agent in relation to the Nodinite Monitoring Service and the servers you monitor determines your firewall configuration. Monitoring the agent's own host needs no ports. The diagram shows every host involved, with the agent on its own server; each arrow starts at the side that opens the connection.

Network diagram: the Monitoring Service calls the agent, and the agent uses WMI/RPC, SMB, and optionally WinRM and the IIS Management Service against each remote Windows Server. Dashed arrows are optional hops.

Note

When the agent runs on the Core Services Server (the typical installation), you need no firewall rule between the Monitoring Service and the agent.

Between the Monitoring Service and the Windows Server Monitoring Agent

The Monitoring Service opens every connection; the agent never calls it. On Windows Server, Nodinite v7 hosts the agent as its own IIS web site, on a port you set per environment in the Nodinite Portal (Servers step).

Option: Service Bus Relaying (cloud or hybrid)

Use Service Bus Relayed connections when Nodinite and the agent are on different networks. Both sides connect outbound to the Azure Relay namespace, so neither server needs an inbound rule. Nodinite uses the same principle as the on-premises data gateway; see 'Adjust communication settings for the on-premises data gateway' and the 'Azure Relay FAQs'. For AMQP tests, see AMQP Port Configuration - 5671 and 5672.

Between the Windows Server Monitoring Agent and remote Windows Servers

Required for WMI, performance counters, services, scheduled tasks, event logs, PowerShell, and IIS on remote servers.

For scheduled tasks and event logs, the remote server must run the Remote Registry (RemoteRegistry), Task Scheduler (Schedule, Automatic), and Windows Event Log (EventLog) services, have File and Printer Sharing enabled, and allow these firewall rule groups. Remote Event Log Management covers event log monitoring and the scheduled task "View History" Remote Action; Remote Scheduled Tasks Management covers monitoring, enabling, disabling, and running tasks.

Enable-NetFirewallRule -DisplayGroup "Remote Scheduled Tasks Management"
Enable-NetFirewallRule -DisplayGroup "Remote Event Log Management"
# Verify rules are enabled
Get-NetFirewallRule -DisplayGroup "Remote Scheduled Tasks Management", "Remote Event Log Management" |
    Select-Object DisplayName, Enabled, Direction

Tip

For "0 tasks and 0 subfolders" or "Access Denied" errors, see How to Monitor Remote Scheduled Tasks.

Add firewall rule

To monitor IIS on a remote Windows Server, add a rule on that server that lets dllhost.exe accept incoming requests from the Nodinite Windows Server Monitoring Agent.

netsh advfirewall firewall add rule name="Remote IIS inetinfo" dir=in action=allow description="Remote IIS Service Managment" program="%systemroot%\System32\inetsrv\inetinfo.exe" enable=yes  

netsh advfirewall firewall add rule name="COM+ Remote Administration (All Programs)" dir=in action=allow description="" program="%windir%\system32\dllhost.exe" enable=yes localport=RPC protocol=tcp  

Between the Windows Server Monitoring Agent and any network device

Between the Windows Server Monitoring Agent and the Domain Controller

Required when the agent authenticates with domain credentials or queries certificates from Active Directory.

Between the servers and DNS

See 'How DNS works on TCP and UDP'.

Important

Stateful Firewalls: Most Windows Firewall implementations are stateful, so response traffic for established outbound connections is allowed automatically. The inbound response rules above are for reference and troubleshooting.

WinRM

Warning

WinRM must be enabled on remote Windows Server if you are using the PowerShell feature with remote target.

Run the scripts below on the remote server to enable WinRM:

The user must have administrator rights on the remote server.

Enable-PSRemoting -Force  

Firewall rules must allow PowerShell Remoting (TCP 5985 for HTTP, TCP 5986 for HTTPS).

New-NetFirewallRule -Name "Allow WinRM" -DisplayName "Allow WinRM" -Enabled True -Profile Any -Direction Inbound -Action Allow -Protocol TCP -LocalPort 5985  

Frequently asked questions

Additional solutions to common problems and the FAQ for the Nodinite Windows Server Monitoring Agent exist in the Troubleshooting user guide.

• 🪲Invalid Class
• ⌛Timeout or Connection Error
• How to Monitor Remote Scheduled Tasks

Next Steps

Install Windows Server Monitoring Agent

Related Topics

Add or manage a Monitoring Agent Configuration
Monitoring
Administration